從理念到介面的設計基礎 From Concept to Interface

我們都能感受到一個 App 用起來順不順手的差別。作為使用者，要分辨這些差異其實很簡單。但作為設計師，要打造那種順暢無阻的體驗就沒那麼簡單了。所以我們就一起來搞清楚怎麼做出那種好用的 App？

1Structure 結構

每一個 App 都建立在一個基礎結構之上，而這個結構決定了後續的一切，使用者如何導航、哪些資訊突出、整體體驗是否清晰連貫。如果結構設計得當，整個體驗就會自然而然地順暢銜接。如果做得不好嘛……我們都體驗過那種混亂感。

這個 App 它是給愛聽黑膠唱片的人用的，可以記錄和整理他們的收藏。你可以滑動看看你有哪些唱片，也許會突然想聽某一張。

你可以把唱片分組、新增新唱片、記錄交換過的，還能收藏未來想買的唱片。

正確的思維方式：Supports discoverability 支援可發現性的思路

所以你第一眼的感覺是什麼？有沒有什麼地方讓你困惑？哪些設計是有效的？又有哪些感覺有點不對勁？

1 Where I am? 首先，”我要知道我現在在哪個頁面”

它能讓使用體驗更友好，讓我操作時更有信心。而這一切的起點是：我需要知道“我現在在 App 的哪裡”。App 應該立即明確這一點， 這樣使用者就不會對自己的位置感到困惑，也不會懷疑是怎麼來到這個頁面的。

2 What can I do? 接下來我會問：“我在這裡能做什麼？

我不應該去猜，操作要直觀、明確，易於理解。

3 Where can I go? 最後我會思考：“我接下來可以去哪裡？”

明確的下一步引導可以維持操作流程的連貫，避免使用者猶豫或反覆思考。

4 當這些問題都能輕鬆回答時，App 的使用體驗就會顯得自然流暢，令人願意繼續使用。

這通常說明 App 有一個紮實的結構基礎。結構設計良好，是一切體驗最佳化的前提。

我們從0-1的最佳化這個黑膠唱片App

乍一看，這 App 看起來還挺順眼的。不過有時候也會被騙，以為它用起來也和看起來一樣好。

1 首先，我要知道我現在在哪個頁面“我在這裡能做什麼？

我本來期望先知道自己在哪，但首先映入眼簾的卻是一個選單。這並不是一個理想的開場方式。選單太泛了，我更想先搞清楚這頁面到底是幹嘛的。

然後是個標題，但它更像是品牌標誌，而不是用來說明內容的。雖然好看，但沒啥用。

我甚至想直接跳過它……但這樣一來，我可能會錯過一些其實挺有用的推薦內容。

再往下滑看到些專輯，但好像只能看看，搞不清楚我在哪，也不知道要幹嘛。

最底下才發現原來這是“唱片”頁面，不過這個資訊來得也太晚了。

結論：這個介面沒有主動引導我，我得自己一點一點拼湊資訊才能搞明白它的用途。這就是當結構不清晰時會發生的事，會明顯感覺到猶豫、困惑，甚至乾脆放棄使用。

Clear information architecture 清晰的資訊架構

可能一開始如果內容沒那麼多，App 會看起來更簡單一點。這正是資訊架構的目標。資訊架構的過程，就是將資訊進行組織和優先順序排序，讓使用者在需要的時候能輕鬆、無障礙地找到他們想要的東西。

List every feature 列出所有功能

做的第一件事是把這個 App 所有的功能列出來， 包括核心功能、使用流程，甚至是那些“有也好”的附加功能。在這個階段，我不會急著評判或刪減任何東西。

Learn from people 向使用者學習

接著我會換位思考，設想別人是怎麼使用這個 App 的。他們會在什麼時間、什麼情境下使用？這款 App 如何融入他們的日常？哪些功能是有幫助的？哪些會干擾他們的使用？然後我把這些問題的答案也補充進之前的功能清單裡。

Organize insights 整理洞察

在這個基礎上，我開始整理內容，刪除不必要的功能、重新命名模糊的內容，並把自然屬於一組的內容歸類到一起。

如果我自己都說不清重點，App 自然也讓使用者搞不清。簡化之後，我就更清楚這個 App 到底是幹嘛的。同時這也讓我更容易規劃使用者是如何發現這些功能的，以及他們會在什麼時候使用它們。

2 Navigation 導航

導航決定了使用者如何在 App 中移動 ，它不只是“點來點去”而已。我希望使用者在使用過程中始終有“方向感”，並對操作充滿信心。所以我會把之前整理好的內容用在標籤欄裡，在 iOS 上它是很常見的導航方式。

Tab bar 標籤欄

Tab bar 支援在 App 的不同主要部分之間切換，並且始終可見，方便使用者隨時訪問核心功能。Tab bar 進行簡化非常關鍵，因為每增加一個標籤，就意味著多一個選擇，這可能讓使用者覺得 App 比實際複雜得多。

What deserves a tab? 哪些功能值得成為標籤？

所以我會先問自己：哪些功能是真的必須的？哪些才該放在底部導航？

比如有一個不適合放進去的例子是“Crates”（唱片箱）。它只是用來分類管理 Records（唱片）的頁面，所以我決定把它合併起來，不再單獨設一個標籤。

然後是“新增”按鈕，它現在也在 Tab bar 中，因為這是 App 的主要操作之一。

不過我有點不確定：它真應該在這嗎？每當我不確定某個元件的使用時機或方式，我都會回去查閱《Human Interface Guidelines》果然，指南上說得很清楚：Tab bar 是用來做導航的，而不是用來觸發操作的。所以我決定把“新增”功能移到“唱片”頁面的內部 ，因為使用者更可能是在瀏覽唱片時新增新內容。

現在的 Tab bar 只保留了三個明確、彼此區分的部分。

而既然我要讓導航更“可預測”，那我覺得標籤的命名方式還可以最佳化一下。我希望標籤文字和圖示本身就能表達每個頁面的功能,這樣使用者無需點進去試，就能知道大概內容，不會因為“不確定”而忽略它。

我會把“Swaps”和“Saves”這兩個標籤改成更直接、易懂的名稱。

同時我也會更換對應的圖示，以強化每個頁面的含義。我希望這些圖示在視覺上保持一致，所以使用 SF Symbols , Apple 提供的一套官方圖示庫。這些圖示使用者在 Apple 各平臺上都很熟悉，這樣能提升識別度和信任感。

透過簡化後的資訊架構、熟悉的圖示和清晰的標籤，整個 App 的結構和用途變得一目瞭然，Tab bar 也顯得更友好易用了。

Toolbar 工具欄

由於前面在資訊架構上的調整，一些內容被重新安排了位置，這讓頁面的內容變得有些混亂。所以我們接下來用工具欄（Toolbar）來把這些混亂梳理清楚。

工具欄是幫助使用者“建立方向感”的好辦法。注意，它解決了我前面提到的兩個問題：“我現在在哪？”以及“我可以做什麼？”

因為工具欄提供了一個清晰的頁面標題，說明當前頁面內容，而不是像之前那樣放一個選單或者品牌標誌。它能幫助使用者瞭解頁面內容的預期，並在瀏覽或滑動時始終保持方向感。

它還能放一些這個頁面特有的操作，不用硬塞到底部導航裡。因為空間有限，我只會放最關鍵的操作，並搭配 SF Symbols 圖示來提高辨識度。

現在我可以清楚地回答：“我在哪”、“我能做什麼”、“App 能做哪些事”。這樣一來，使用者從一開始就能獲得更安心、更有把握的使用體驗。

這一切得益於前期對結構的梳理，以及對導航元件的有意識使用。每改一次，設計就更接近理想，更清晰、更好用，也更順。

3 Content 內容

接下來我們來聚焦介面上實際呈現的內容。App 的內容應該經過合理組織，引導使用者關注最重要的部分，以及他們最希望首先看到的資訊。

Organization 組織架構

頁面看起來很雜亂，因為有兩種不同型別的內容混在一起：分組（Groups）和唱片（Records）。

那我就先簡單點，直接把“分組”和“唱片”分成兩個部分。起碼現在看得出來內容是啥，但不滑到底我還看不到後面的東西。

Progressive disclosure 漸進式展示

那如果我只展示幾個分組，然後讓使用者逐步探索更多內容呢？

這個設計原則叫做“漸進式揭露”（progressive disclosure）。它的核心在於：一開始只展示必要的內容，夠使用者啟動操作即可，之後再透過互動逐步展現更多資訊。這種做法在很多地方都能看到，介面一開始很簡潔，之後才逐步提供更多細節或進階功能。

所以那些“看不到”的內容其實沒有被刪除，而是藏在標題旁邊的一個“展開控制按鈕”後面，等使用者需要的時候再展示。而當使用者點開那個頁面後，我希望內容的排布方式與之前保持一致。這樣就讓使用者感覺當前介面是對上一個介面的“自然擴充套件”，而不是跳到了一個陌生的新地方。

就像導航部分一樣，每一個介面都必須提供方向感，所以這一次我們也不能忘記加上工具欄。

工具欄上應該有和當前頁面相關的操作按鈕，以及返回按鈕，這樣使用者就知道自己是怎麼來到這個頁面的，也知道怎麼回去。

Layout 版式

在我最初的設計中，有些元素只是裝飾，或者沒有明確功能，這導致真正重要的功能難以被發現。所以現在我更傾向於做出更“聰明”的設計選擇，用最清晰的方式去展示內容。

漸進式揭露這個方向是對的，但當前使用的網格佈局（grid layout）卻有些不合適。網格佈局在只展示兩個專案時佔用了太多空間，顯得浪費。而且這種佈局不適合展示較長的文字，導致內容表達不清楚。

那我來改進一下這個問題。使用“列表佈局”效果更好。它靈活、實用，使用者也非常熟悉，特別適合展示結構化資訊，並支援快速瀏覽。列表相比於影象佈局佔用更少的垂直空間，這樣一來，可以在同一屏中展示更多內容項。

你不需要完全從零開始設計的，透過 Tab bar 和 Toolbar 的經驗我學到：優先考慮功能性，總是值得的。所以我採用了 Apple Design Resources 中的列表模板，它非常容易適配我的內容。現在看起來，這個設計更有條理、功能也更全了，像是個真 App 了。

https://developer.apple.com/design/resources/

我們再來看最後一部分的設計。滑動頁面後，我能看到使用者上傳的所有唱片。我最初的目標是讓所有內容一開始就全部呈現，方便使用者隨意瀏覽探索。

但隨著選項越來越多，使用者處理這些資訊所需的精力也急劇上升。我怕使用者根本看不完，直接退出 App 了。

展示之前，得先把內容整理好，不然全堆一起怎麼擺都不合適。把內容按主題分組，可以去掉干擾，讓重點更清晰。

哪怕內容沒啥圖、也不是天天更新，分組一樣能幫我們減少選擇壓力，還能讓人覺得這個 App 很懂我。所以我確定我自己一定會用這些策略。

要是需要展示很多圖片內容，那就該用集合檢視（Collection）來處理了。這種方式特別適合展示可以滑動瀏覽的一大堆東西，比如照片、影片或商品。我特別喜歡它帶來的那種“動態感”。為了讓它看起來整潔，我讓每個專案之間的間距統一，也儘量不在圖上堆文字。

我用之前提到的分組策略來構建這些集合：

我按時間分，比如“夏天推薦”；

按進度分，比如“已集齊系列”；

按風格分，比如“爵士”“電子”之類。

當內容排得清楚，用的又是大家熟的元件，使用者就能輕鬆找到重點，還會想一用再用。

4 Visual design 視覺設計

有時候一開啟 App，就覺得特別順眼，這就是視覺在起作用。視覺設計傳達了 App 的個性，也影響使用者的情感感受。視覺設計就是要把層次、字型、圖片和顏色搭配好，還得保證好用。想讓視覺更出色，我得先看清楚哪裡好用，哪裡還能改進。

Supports function 支援功能性

我仔細看字型、顏色和影象是怎麼配合的。我眯著眼一看，最先注意到的是第一組內容，因為那裡顏色最亮、最搶眼。可是這樣一來，其他內容我就看不到了，也搞不清自己在整個頁面的哪個位置。

這裡缺失的是“視覺層級”。視覺層級的目的，是引導使用者的視線按重要性順序瀏覽頁面上的設計元素。

為了改善視覺層級，我打算把最重要的部分變成“視覺錨點”：比如讓它變大、增強對比度，這樣它就能自然而然地吸引注意力。

Use text styles 使用文字樣式

但這個設計能應對變化嗎？比如文字變長、語言不同，或者使用者啟用了更大的文字尺寸？我意識到我需要讓設計更具“靈活性”，特別是在字型排版方面。

這時候，“系統文字樣式”就派上用場了。它們可以在不同的螢幕設定下（如深色模式、大字號）依然保持清晰的層級和良好的可讀性。這些樣式覆蓋了從標題到說明文字的各個等級，用它們我就不用自己一個個調字號了，還能很清楚地表達出哪些內容更重要，也避免了“靠感覺”排版。

我保留“滿屏影象”（full-bleed）的設計風格，並把專輯封面移到背景中。這樣文字就有了穩定的佈局空間，同時透過三種不同的文字樣式在大小和對比度上形成差異，有效引導使用者視線。

系統文字樣式還支援“動態文字”（Dynamic Type），讓使用者可以根據自己的需要調整字號，從而讓 App 更具包容性，對所有人都更友好易用。

但當文字疊加在影象上時，可讀性很容易出問題，尤其是背景圖複雜或對比度很高的情況下。在這種情況下，“清晰度”必須優先考慮。

解決這個問題的一個簡單方法是：在文字背後加一個淡淡的背景，比如漸變或模糊。這種做法能提升文字的可讀性，同時也增加了視覺層次感，而不會破壞原有設計。

Use images and color intentionally 有目的地使用影象和顏色

最後一個重點是：影象和顏色如何幫助傳達 App 的“個性”。我從“列表”部分開始最佳化。我覺得好像簡化過頭了，結果列表都快被淹沒在別的東西里了。

所以我決定為每個分組加上影象，這樣列表更易於快速瀏覽和識別。

可是並不是所有圖片都好用，有的效果反而不好。它們在顏色和風格上差異很大。

Use a cohesive style 採用統一的風格

這讓我意識到：我真正需要的是一個統一、協調的視覺風格。

為了做到這一點，我先選定了一組色彩搭配（色板），併為其制定一些簡單的使用規則。這樣看起來就有統一感了，也更容易讓使用者感受到想傳達的氣氛。

我選了四種顏色，加上一些復古的圖形元素，再自由組合。有些分組有標題，我就用了一種更粗更寬的字型，這樣和列表裡的其他字不一樣。

我挺喜歡現在的樣子，這些設計讓 App 更有個性，也方便以後繼續擴充套件而不亂。

Semantic colors 語義顏色

既然在調顏色，我就想看看還有哪些地方可以加點顏色，讓畫面更好看又更實用。背景、文字、圖示這些地方其實都有顏色，不過不是我挑的，是系統預設的那種顏色。

它們並不是真正意義上的“黑色”或“紫色”，而是像 label（標籤色）、secondarySystemBackground（二級系統背景）這樣的“語義色”。

這些叫“語義顏色”（semantic colors），它們是按照用途命名的，而不是按顏色外觀 —— 因為它們具有動態變化的能力。它們會根據系統的對比度設定、螢幕環境，以及“淺色/深色模式”等自動調整外觀。

我可以在一些地方使用點綴色（accent color）—— 比如按鈕、控制元件、或是高亮選中狀態。但我得特別小心，不能讓這些顏色妨礙動態模式的切換、降低整體可讀性，或者影響使用者的視覺舒適度。所以對任何需要動態響應的介面部分來說，系統語義色其實就是我“預設的色彩系統”。

這些顏色都在 Apple 的官方設計資源裡，能幫我輕鬆建立清晰的視覺層次，又能自動適應使用者喜歡的外觀，無需額外操作。這正好教會我，什麼時候該用系統自帶的東西，什麼時候又能加一點自己的風格。

有時候我們會想把每個元素都當成一個小專案來做，其實也沒錯，這些都值得花時間去研究。但真正有效的設計，不是每個元素單打獨鬥，而是它們共同協作，為介面的整體意義和體驗服務。我簡化了結構、理清了導航、內容也更清楚了，使用者用起來更容易，也更舒服。

Design is never really finished, and there’s no single right answer.

設計永遠做不完，也不可能有唯一的“正確答案”。